Skip Headers

Oracle® Database Backup and Recovery Advanced User's Guide 10g Release 2 (10.2) Part Number B14191-02 |
Home | Book List | Contents | Index | Master Index | Feedback

Previous | Next
| View PDF

# RMAN Restore and Recovery Examples

The following sections illustrate the use of RMAN restore and recovery techniques in advanced scenarios.

## Restoring Datafile Copies to a New Host: Example

To move the database to a new host by means of datafile copies, you must transfer the copies manually to the new machine. This example assumes that you are using a recovery catalog.

1. After connecting to the target database and recovery catalog, run a `LIST` command to see a listing of datafile copies and their associated primary keys, as in the following example:

       LIST COPY;

2. Copy the datafile copies to the new host with an operating system utility. For example, in UNIX:

       % cp -r /tmp/*dbf /net/new_host/oracle/oradata/trgt

3. Start RMAN and then uncatalog the datafile copies on the old host. For example, enter:

       CHANGE COPY OF DATAFILE 1,2,3,4,5,6,7,8 UNCATALOG;

4. Catalog the datafile copies, using their new filenames or `CATALOG START` `WITH` (if you know all the files are in directories with a common prefix easily addressed with a `CATALOG START WITH`). For example, run:

       CATALOG START WITH '?/oradata/trgt/';

   Or this example specifies files individually:

       CATALOG DATAFILECOPY
         '?/oradata/trgt/system01.dbf', '?/oradata/trgt/undotbs01.dbf',
         '?/oradata/trgt/cwmlite01.dbf', '?/oradata/trgt/drsys01.dbf',
         '?/oradata/trgt/example01.dbf', '?/oradata/trgt/indx01.dbf',
         '?/oradata/trgt/tools01.dbf', '?/oradata/trgt/users01.dbf';

5. Perform the restore and recovery operation described in "Performing Disaster Recovery".

## Restoring Control File When Databases in the Catalog Have the Same Name: Example

When using a recovery catalog and attempting to restore a lost control file, you encounter an error if there are other databases are registered in the recovery catalog with the same name as your target database.

To resolve this error, you must uniquely identify the database by DBID for the restore operation. This requires determining the correct DBID for your database, and then using the `SET` `DBID` command to identify the target database before the `RESTORE` `CONTROLFILE` command, as shown in the following example:

1. Start RMAN and connect to the target database.

2. Run the `STARTUP` `FORCE` `NOMOUNT` command.

3. Run the `SET` `DBID` command to distinguish this connected target database from other target databases that have the same name.

4. Run the `RESTORE` `CONTROLFILE` command. After restoring the control file, you can mount the database to restore the rest of the database.

See Also: Oracle Database Backup and Recovery Reference for more details on the use of `SET` `DBID.`

### Restoring a Backup Control File By Using the DBID

To set the DBID, connect RMAN to the target database and run the following `SET` command, where `target_dbid` is the value you obtained from the previous step:

    SET DBID = target_dbid;

To restore the control file to its default location and then mount it, run:

    RESTORE CONTROLFILE;
    ALTER DATABASE MOUNT;

To restore and recover the database, run:

    RESTORE DATABASE;
    RECOVER DATABASE
      # optionally, delete logs restored for recovery and limit disk space used
      DELETE ARCHIVELOG MAXSIZE 2M;

## Recovering a Lost Datafile Without a Backup: Example

RMAN can handle lost datafiles without user intervention during restore and recovery. When a datafile is lost, the possible cases can be classified as follows:

- The control file knows about the datafile, that is, the user backed up the control file after datafile creation, but the datafile itself is not backed up. If the datafile record is in the control file, then `RESTORE` creates the datafile in the original location or in a user-specified location (for example, with `SET` `NEWNAME`). The `RECOVER` command can then apply the necessary logs to the datafile.

- The control file does not have the datafile record, that is, the user did not back up the control file after datafile creation. During recovery, the database will detect the missing datafile and report it to RMAN, which will create a new datafile and continue recovery by applying the remaining logs. If the datafile was created in a parent incarnation, it will be created during restore or recover as appropriate.

In this example, the following sequence of events occurs:

1. You make a whole database backup of your `ARCHIVELOG` mode database.

2. You create a tablespace `history` containing a single datafile called `/mydb/history01.dbf`.

3. You populate the newly created datafile with data.

4. You archive all the active online redo logs.

5. A user accidentally deletes the datafile `history01.dbf` from the operating system before you have a chance to back it up.

In this case, the current control file knows about the datafile. To restore and recover the datafile, start RMAN, connect to the target database, and then enter the following commands at the RMAN prompt:

    # take the tablespace with the missing datafile offline
    SQL "ALTER TABLESPACE history OFFLINE IMMEDIATE";
    # restore the tablespace even though you have no backup
    RESTORE TABLESPACE history;
    # recover tablespace
    RECOVER TABLESPACE history;
    # bring the recovered tablespace back online
    SQL "ALTER TABLESPACE history ONLINE";